home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9704 / 000016_owner-urn-ietf _Tue Apr 15 09:56:16 1997.msg < prev    next >
Internet Message Format  |  1997-04-30  |  7KB
  1. Received: (from daemon@localhost)
  2.     by services.bunyip.com (8.8.5/8.8.5) id JAA26600
  3.     for urn-ietf-out; Tue, 15 Apr 1997 09:56:16 -0400 (EDT)
  4. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
  5.     by services.bunyip.com (8.8.5/8.8.5) with SMTP id JAA26595
  6.     for <urn-ietf@services.bunyip.com>; Tue, 15 Apr 1997 09:56:12 -0400 (EDT)
  7. Received: from mrelay.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  8.         id AA11876  (mail destined for urn-ietf@services.bunyip.com); Tue, 15 Apr 97 09:55:46 -0400
  9. Received: from  jrc.it (elect6.jrc.it) by mrelay.jrc.it (4.1/EB-950131-C)
  10.     id AA15921; Tue, 15 Apr 97 16:02:09 +0200
  11. Received: by  jrc.it (5.x/EB-950213-L)
  12.     id AA11458; Tue, 15 Apr 1997 15:54:39 +0200
  13. Date: Tue, 15 Apr 1997 15:54:39 +0200
  14. From: "Dirk.vanGulik" <Dirk.vanGulik@jrc.it>
  15. Message-Id: <9704151354.AA11458@ jrc.it>
  16. To: urn-ietf@bunyip.com
  17. Subject: [URN] Glossary, rough cut
  18. X-Sun-Charset: US-ASCII
  19. Sender: owner-urn-ietf@Bunyip.Com
  20. Precedence: bulk
  21. Reply-To: "Dirk.vanGulik" <Dirk.vanGulik@jrc.it>
  22. Errors-To: owner-urn-ietf@Bunyip.Com
  23.  
  24. All credits go to Ron, for providing this start. Any additional
  25. typo's and mistakes are mine. I also went over all our current drafts
  26. with a college; and added the words she spotted as not obvious
  27. as to their meaning.
  28.  
  29. I am not sure how far this document should go; I feel it should
  30. not muddle the waters of the framework document by re-defining
  31. some of its terms.
  32.  
  33. Depending on how many updates are posted; I will either re-post
  34. the edited version once a week or once a month. Either send
  35. updates to me directly; or to the list, or even both. 
  36.  
  37. If you like web/mail interfaces; at 
  38.  
  39.     http:/www.ceo.org/urn/show.pl
  40.  
  41. you should be able to find the latest CVS version. There is
  42. a hacked update form. But mail will do just fine.
  43.  
  44. Thanks
  45.  
  46. Dw.
  47.  
  48. ----
  49.  
  50.                         URN Glossary
  51.  
  52. Introduction
  53.  
  54. The Uniform Resource Names (URN) working group of the Internet Engineering
  55. Task Force is specifying a framework for URNs and first implementations
  56. of the components of the framework. A particular vocabulary has been
  57. developed during that effort, but the vocabulary has not been codified
  58. and used uniformly in all the draft documents of that working group.
  59. This document's purpose is to define the terms used in the URN-WG
  60. documents. We do this in two ways. The next section is a paragraph
  61. that briefly describes the efforts of the URN-WG, and uses all the
  62. terms. The second section is a glossary listing the terms in alphabetical
  63. order and providing definitions for them.    (Ron's)
  64.  
  65. Terms In Context:
  66.   
  67. The URN Framework is based on two dichotomies. The first is a separation
  68. of namespaces and resolution mechanisms. Since we expect resolution
  69. mechanisms to evolve over time, they must be capable of resolving
  70. identifiers that do not contain resolution-system specific hints. The
  71. second dichotomy is a distinction between resolvers and resolver
  72. discovery services. Resolvers are the systems that contain a database of
  73. URNs and things to which they may resolve. Resolvers offer certain
  74. resolution services, such as mapping a URN to the location of the
  75. resource. When clients communicate with a resolver to obtain one of
  76. those services, they do so using a particular resolution protocol. We
  77. expect that resolution services and protocols will change over time. We
  78. also expect that the location of resolvers will change over time.
  79. Therefore we need a way to discover the location of resolvers and
  80. determine the protocols and services they offer. That is the role of
  81. resolver discovery services. (Ron's)
  82.  
  83. Glossary
  84. ========
  85.  
  86. Absolute/Relative/Path URNs
  87.  
  88. Local Resolver, Fallback Resolver
  89.     (Karen uses "local resolver" to mean "resolver". I use it to refer
  90.     to resolvers that are close to the client and are contacted early.
  91.     If the local resolver can't answer the query, then a fallback resover is
  92.     used.)
  93.  
  94. Must/Shall 
  95.      Software that does not behave in the manner that this
  96.      document says it must is not conformant to this document.
  97.  
  98. NAPTR
  99.  
  100. NID
  101.     Name space identifier; which uniquely places a URN in single namespace.
  102.  
  103. Name Delegation
  104.  
  105. Namespace
  106.     A space of identifiers governed by a common set of rules on syntax
  107.     and semantics.
  108.  
  109. RCDS
  110.      Resource Cataloging and Distribution Service. A UDP based protocol
  111.  
  112. RFC1713
  113.  
  114. Resolution Mechanism
  115.     The mechanism used to resolve a URI into a resource or another URI.
  116.  
  117. Resolution Protocol
  118.     The protocol used for a client to communicate with a resolver. Some
  119.     resolvers may offer multiple protocols.    
  120.  
  121. Resolution Service
  122.     A service offered by a resolver. Example services are mapping an
  123.     identifier to metadata for the resource, mapping an identifier to
  124.     a set of aliases, or mapping the identifier to the resource it
  125.     denotes. The resolution services that a resolver may offer are
  126.     determined by the schema of the resolver database.
  127.  
  128.     Example Resolution Services
  129.             N2L  - Given a URN, return a URL
  130.             N2Ls - Given a URN, return a set of URLs
  131.             N2R  - Given a URN, return an instance of the resource.
  132.             N2Rs - Given a URN, return multiple instances of the resouce,
  133.                    typically encoded using multipart/alternative.
  134.             N2C  - Given a URN, return a collection of meta-information on
  135.                    the named resource. The format of this response is the
  136.                    subject of another document.
  137.             L2R  - Given a URL, return the resource.
  138.             L2C  - Given a URL, return a description of the resource.
  139.  
  140. Resolver
  141.     A server which offers a Resolution Service. To this purpose it 
  142.     might contain, or be tightly integrated with, a database of 
  143.     URIs, their mapping and associated information. 
  144.  
  145. Resolver Discovery Service (RDS):
  146.     A method for discovering resolvers. 
  147.  
  148. Resource
  149.  
  150. SRV
  151.  
  152. Should
  153.      Software that does not follow the behavior that this document
  154.      says it should may still be conformant, but is probably broken
  155.      in some fundamental way.
  156.  
  157. URC
  158.      Universal Resource Characteristics, essentially Metadata in a
  159.      TBD format, such as the dublin core.
  160.  
  161. URI
  162.     Uniform Resource Identifiers are the superclass of URNs and URLs.
  163.  
  164. URN
  165.     Uniform Resource Names are persistent, location-independent identifiers
  166.     for network-accessible resources.
  167.  
  168. Vanity Names
  169.  
  170. Acknowledgements:
  171. =================
  172.  
  173. The author would like to thank Ron Daniel for most of the entries
  174. in this list. 
  175.  
  176. References:
  177. ===========
  178.  
  179. [1] RFC-1737 "Functional Requirements for Uniform Resource Names", Karen
  180.     Sollins and Larry Masinter, Dec. 1994.
  181.  
  182. [2] draft-daigle-urn-framework-??.txt "A Uniform Resource Naming
  183.     Framework", Leslie Daigle and Patrik Faltstrom, June, 1996.
  184.  
  185.  
  186. Security Considerations
  187. =======================
  188.  
  189. Security was pondered upon, and is considered not to be an issue
  190. for a glossary.
  191.  
  192. Author Contact Information:
  193. ===========================
  194.  
  195. Dirk-Willem van Gulik / Dirk.vanGuliK@jrc.it
  196.  
  197. http://www.ceo.org/urn/gloss.html
  198.